# Member-level security

The data model serves as a facade of your data. With member-level security,
you can define whether [data model entities][ref-data-modeling-concepts] (cubes, views,
and their members) are exposed to end users and can be queried via [APIs &
integrations][ref-apis].

Member-level security in Cube is similar to column-level security in SQL databases.
Defining whether users have access to [cubes][ref-cubes] and [views][ref-views] is
similar to defining access to database tables; defining whether they have access
to dimensions and measures — to columns.

__By default, all cubes, views, and their members are *public*,__ meaning that they
can be accessed by any users and they are also visible during data model introspection.

## Managing member-level access

You can use [data access policies][ref-dap] to configure member-level access
for different [roles][ref-dap-roles]. With the `access_policy` parameter in
[cubes][ref-ref-cubes] and [views][ref-ref-views], you can define which members
are accessible to users with specific roles.

<InfoBox>

In [development mode][ref-dev-mode] in [Playground][ref-playground], access
control checks are disabled and all access policies are not evaluated. It helps
you conveniently debug the data model by querying any members in
API queries and during data model introspection.

</InfoBox>

Use the `member_level` parameter to specify either:
- `includes`: a list of allowed members, or
- `excludes`: a list of disallowed members

You can use `"*"` as a shorthand to include or exclude all members.

In the following example, member-level access is configured for different roles:

<CodeTabs>

```yaml
views:
  - name: orders_view
    cubes:
      - join_path: orders
        includes:
          - status
          - created_at
          - count
          - count_7d
          - count_30d
    
    access_policy:
      # Default policy: no access for users without specific roles
      - role: "*"
        member_level:
          includes: []
      
      # Managers can access all members except for `count`
      - role: manager
        member_level:
          excludes:
            - count
      
      # Observers can access all members except for `count` and `count_7d`
      - role: observer
        member_level:
          excludes:
            - count
            - count_7d
      
      # Guests can only access the `count_30d` measure
      - role: guest
        member_level:
          includes:
            - count_30d
```

```javascript
view(`orders_view`, {
  cubes: [
    {
      join_path: orders,
      includes: [
        `status`,
        `created_at`,
        `count`,
        `count_7d`,
        `count_30d`
      ]
    }
  ],

  access_policy: [
    {
      // Default policy: no access for users without specific roles
      role: `*`,
      member_level: {
        includes: []
      }
    },
    {
      // Managers can access all members except for `count`
      role: `manager`,
      member_level: {
        excludes: [
          `count`
        ]
      }
    },
    {
      // Observers can access all members except for `count` and `count_7d`
      role: `observer`,
      member_level: {
        excludes: [
          `count`,
          `count_7d`
        ]
      }
    },
    {
      // Guests can only access the `count_30d` measure
      role: `guest`,
      member_level: {
        includes: [
          `count_30d`
        ]
      }
    }
  ]
})
```

</CodeTabs>

This configuration results in the following access:

| Role | Access |
| --- | --- |
| `manager` | All members except for `count` |
| `observer` | All members except for `count` and `count_7d` |
| `guest` | Only the `count_30d` measure |
| All other users | No access to this view at all |

Access policies also respect member-level security restrictions configured via
`public` parameters. For more details, see the [data access policies
reference][ref-dap-ref].

## Using the public parameter

You can explicitly make a data model entity public or private by setting its
`public` parameter to `true` or `false`. This parameter is available for
[cubes][ref-cubes-public], [views][ref-views-public], [measures][ref-measures-public],
[dimensions][ref-dimensions-public], [hierarchies][ref-hierarchies-public], and
[segments][ref-segments-public].

You can also control whether a data model entity should be public or private
[dynamically][ref-dynamic-data-modeling] by using the [security context][ref-security-context].

<WarningBox>

While the `public` parameter provides a simple way to restrict access, it applies
globally to all users. __It is recommended to use [data access policies][ref-dap]
by default__ as they allow you to define granular access control rules
in one place.

</WarningBox>


[ref-data-modeling-concepts]: /product/data-modeling/concepts
[ref-apis]: /product/apis-integrations
[ref-cubes]: /product/data-modeling/concepts#cubes
[ref-views]: /product/data-modeling/concepts#views
[ref-dap]: /product/auth/data-access-policies
[ref-dap-roles]: /product/auth/data-access-policies#data-access-roles
[ref-ref-cubes]: /product/data-modeling/reference/cube
[ref-ref-views]: /product/data-modeling/reference/view
[ref-dev-mode]: /product/configuration#development-mode
[ref-playground]: /product/workspace/playground
[ref-dap-ref]: /product/data-modeling/reference/data-access-policies
[ref-cubes-public]: /product/data-modeling/reference/cube#public
[ref-views-public]: /product/data-modeling/reference/view#public
[ref-measures-public]: /product/data-modeling/reference/measures#public
[ref-dimensions-public]: /product/data-modeling/reference/dimensions#public
[ref-hierarchies-public]: /product/data-modeling/reference/hierarchies#public
[ref-segments-public]: /product/data-modeling/reference/segments#public
[ref-dynamic-data-modeling]: /product/data-modeling/dynamic
[ref-security-context]: /product/auth/context